Network Working Group J. Yu 

Request for Comments: 4694 NeuStar 

Category: Standards Track October 2006 
Number Portability Parameters for the "tel" URI 


Status of This Memo 
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and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 
This document defines five parameters in the "tel" Uniform Resource 
Identifier (URI) to carry the number portability (NP)-related 
information. Those parameters can be passed to the next-hop network 


node after an NP database dip has been performed. 
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Introduction 


Number portability (NP) [RFC3482] allows telephony subscribers to 
keep their telephone numbers when they change service provider 
(service provider portability), move to a new location (location 
portability), or change the subscribed services (service 
portability). The telephone numbers can be the geographical 
telephone numbers, mobile telephone numbers, freephone numbers, or 
other types of non-geographical telephone numbers. Some mobile 
telephone numbers are like geographical telephone numbers (e.g., 
those in North America) and others are of non-geographical nature but 
their routing is similar to the routing of geographical telephone 
numbers so they are not specifically mentioned in this document. The 
freephone numbers are also known as toll-free phone numbers. The 
called party who is assigned the freephone number pays the call 
charge when the caller dials the freephone number. 


NP impacts call signaling and routing. One impact is the need to 
carry the NP-related information in the "tel" Uniform Resource 
Identifier (URI) [RFC3966] for protocols such as the Session 
Initiation Protocol (SIP) [RFC3261] and H.323 [H323] after the NP 
database dip has been performed. Another impact is for a Voice over 
IP (VoIP) server to use the NP-related information in a received 
"tel" URI to determine routing. 


A routing number is associated with a geographical or mobile 
telephone number that has been ported out from a donor carrier to 
another carrier. A donor carrier is the initial carrier where a 
geographical telephone number was allocated before ever being ported. 
A "non-ported" geographical or mobile telephone number does not have 
any routing number associated with it because the first N digits of 
the geographical or mobile telephone number can be used for routing. 
A routing number can also be used to indicate the switch or network 
node that originates a call or service similar to the Jurisdiction 
Information Parameter in Signaling System Number 7 (SS7) Integrated 
Services Digital Network User Part (ISUP). The "rn" parameter 
carries the routing number information. The "rn-context" parameter 
describes how the "rn" parameter value should be interpreted when the 
value is not a "global-rn" as is discussed in Section 4. 


The NP database dip indicator is used to inform the downstream 

servers or switches during call setup that there is no need to 

perform the NP database dip for a geographical telephone number 
again. The "npdi" parameter carries such an indicator. 
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A Carrier Identification Code (CIC) identifies the current freephone 
service provider for a freephone number. This parameter can also be 
used to carry the pre-subscribed or dialed long-distance carrier 
information; however, that is outside the scope of this document. 
The "cic" parameter carries the CIC information. The "cic-context" 
parameter describes how the "cic" parameter value should be 
interpreted when the value is not a "global-cic" as is discussed in 
Section 4. 


Conventions 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Abbreviations 


ABNF Augmented Backus-Naur Form 
ANSI American National Standards Institute 


GIC Carrier Identification Code (also cic) 
CIP Carrier Identification Parameter 

FCI Forward Call Indicator 

GAP Generic Address Parameter 


GSTN Global Switched Telephone Network 
HTML HyperText Markup Language 


IC Identification Code 

ISUP Integrated Services Digital Network User Part 
JIP Jurisdiction Information Parameter 

NP Number Portability 


NPDB Number Portability Database 
npdi NP Database Dip Indicator 


rn Routing Number 

PNTI Ported Number Translation Indicator 
SIP Session Initiation Protocol 

SS7 Signaling System Number 7 

URI Uniform Resource Identifier 


VoIP Voice over IP 
Formal Syntax 


The following syntax specification uses the Augmented Backus-Naur 
Form (ABNF) as described in RFC 4234 [RFC4234] and defines the five 
parameters, rn, npdi, cic, rn-context and cic-context, by extending 
the "parameter" production rule of the "tel" URI defined in 
[RFC3966]. 
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parameter =/ rn / cic / npdi 
rn = ";rn="(global-rn / local-rn) 
npdi = ";npdi" 
cic = ";cic=" (global-cic / local-cic) 
global-rn = global-hex-digits 
local-rn = 1*hex-phonedigit rn-context 
rn-context = ";rn-context=" rn-descriptor 
rn-descriptor = domainname / global-hex-digits 
global-hex-digits = "+" 1*3(DIGIT) *hex-phonedigit 
hex-phonedigit = HEXDIG / visual-separator 
visual-separator Se of SCM a. 
domainname = *( domainlabel "." ) toplabel ["."] 
domainlabel = alphanum 

/ alphanum *( alphanum / "-" ) alphanum 
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 
alphanum = ALPHA / DIGIT 
global-cic = global-hex-digits 


local-cic 1*hex-phonedigit cic-context 
cic-context = ";cic-context=" rn-descriptor 


The "rn", “"npdi", or "cic" parameter each can appear in the "tel" URI 
at most once. 


The first "hex-phonedigit" value in "local-rn" or "local-cic" MUST be 
a hex-decimal digit. 


For a "global-rn", the routing number information after "+" MUST 
begin with a valid E.164 [E164] country code. Hexadecimal digit is 
allowed after the country code in the "global-rn". 


For a “"local-rn", the routing number in the "rn" parameter MUST be 
interpreted according to the "rn-context". For example, if a 
national routing number is in the "rn" parameter, the "rn-context" 
MUST contain a valid E.164 country code after "+" if it is in the 
"global-hex-digits" format. Hexadecimal digit is allowed in the 
"local-rn". 


For a "global-cic", the CIC information after "+" MUST begin with a 
valid E.164 country code. 


For a "local-cic", the CIC value in the "cic" parameter MUST be 
interpreted according to the "cic-context". For example, if the 
national CIC value is in the "cic" parameter, the "cic-context" MUST 
contain a valid E.164 country code after "+" if it is in the 
"global-hex-digits" format. 


The inclusion of the visual separator in the "rn" or "cic" is 
optional. 
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Normative Rules 


There are two distinct uses for the "tel" URI. In one use, the "tel" 
URI appears in a piece of static content. For example, it might 
appear in a HyperText Markup Language (HTML) page or a presence 
document. In another use, the "tel" URI appears in call signaling 
protocols, such as SIP and H.323, where it is used to guide routing 
of the call setup messages. The "tel" URI extensions defined in this 
document are targeted at call signaling protocols. When a "tel" URI 
is placed in static content, the parameters defined here SHOULD NOT 
be present, and any entity receiving them SHOULD remove them prior to 
using the tel URI. 


Within the context of signaling protocols, these parameters are meant 
for usage between call signaling entities, called network nodes, 
among which there is a trust relationship. Since parameters inserted 
by one network node can impact the routing of a request at a 
downstream node, processing of these parameters depends on trusting 
that the upstream element properly followed the rules defined here. 

A call signaling protocol can verify that an upstream element is part 
of its circle of trust through hop-by-hop integrity mechanisms. See 
Section 7, Security Considerations, for more information. If a 
network node receives a call signaling message from an element it 
does not trust, it SHOULD ignore the parameters. 


This section discusses how a network node handles a received "tel" 
URI that contains one or more of the parameters defined in this 
document or has accessed an NP database for a freephone number or 
geographical telephone number and needs to add some of the parameters 
defined in this document to a "tel" URI. 


In countries where there is no freephone number portability or 

geographical telephone number portability, the call routing can be 
based on the leading digits of the freephone number or geographical 
telephone number. This document does not describe those scenarios. 


Please note that two accesses to the freephone databases are normally 
done for routing a call to a freephone number. The first one is done 
by the originating network that queries a freephone database for the 
CIC information so that the call can be routed to the serving 
freephone service provider of the called freephone number. When the 
call reaches the serving freephone provider, the second database 
access is performed to map the freephone number to a geographical 
telephone number and/or internal routing information. This document 
does not address the case where internal routing information is 
returned. 
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The first freephone database contains the CIC information for all the 
active freephone numbers, whereas the second one usually contains 
mapping information only for those freephone numbers served by a 
freephone service provider. Because the originating carrier may 
provide freephone service, its freephone database would contain the 
CIC information for all the active freephone numbers plus the mapping 
information for those freephone numbers it serves. This document 
refers to the two database accesses as "the first freephone database 
access" and "the second freephone database access". 


When handling the "rn" and "cic" parameters and the phone numbers in 
the "tel" URI for purposes such as database access and routing, the 
visual separators in them are removed before using the information in 
them. 


When a network node handles a "tel" URI that contains invalid "rn" or 
"cic" information, it may release the call or drop the invalid 
parameter and access the appropriate NP database or freephone 
database to see whether it can retrieve a valid routing number for a 
geographical telephone number or valid CIC for the freephone number. 


When a "tel" URI is received from an untrusted source, a network node 
MAY redo the NPDB query. 


SIP [RFC3261] has mechanisms in place to detect routing loops due to 
URI re-writing, and the new parameters added here work within these 
established contexts. The "npdi" parameter in the URI that indicates 
a NPDB query has already been done can also prevent routing loop. 
Other protocols considering using these "tel" URI parameters SHOULD 
ensure that they have mechanisms in place to detect loops when re- 
writing the "tel" URI. 


1. Handling "tel" URI with NP Parameter or Parameters 


If the "tel" URI contains the "npdi" parameter, the network node MUST 
NOT retrieve the NP-related information for geographical telephone 
numbers even if it is set to do so. 


If the "tel" URI contains the "cic" parameter whose CIC value is 
different from the one this network node is associated with, this 
network node MUST NOT retrieve the NP-related information for the 
geographical telephone number or perform the first freephone database 
access for the freephone number in the "tel" URI. 


For the "cic" and "rn" parameters and either a freephone number or 
geographical telephone number, the order of processing is to look for 
the "cic" parameter first for call routing. If the CIC information 
is not useful or the "cic" parameter does not exist, then the next 
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step is to look for the "rn" parameter. If the information in the 
"rn" parameter is not useful or the "rn" parameter does not exist, 
then the freephone number or geographical telephone number is used. 


If the network node does not know how to route based on the "cic" or 
"rn" parameter, the local policies MUST decide whether to stop the 
call processing or continue the call processing by ignoring the 
invalid/unknown information. 


When looking for the "cic" parameter and that parameter exists in the 
"tel" URI: 


- The network node MUST ignore the "cic" parameter if the CIC 
identifies a carrier or service provider associated with that node 
and look for the "rn" parameter for making the routing decision. 
It MUST remove the "cic" parameter when it routes the call to the 
next-hop network node that belongs to another carrier or service 
provider. 


-— The network node MUST invoke special handling process if the "cic" 
parameter contains a code that requires such a treatment. For 
example, a CIC value of "0110" in the response to a freephone DB 
query in North America indicates "local, translated geographical 
telephone number provided". In this particular example, the "cic" 
parameter is ignored. Please note that this particular CIC value 
of "+1-0110" normally will not appear in the call setup message. 
It is given as an example to show that such special CIC values may 
exist. The exact code values and the handling of them are outside 
the scope of this document. 


- Otherwise, the network node MUST make the routing decision based on 
the CIC. The network node MUST NOT remove the "cic" parameter 
unless it is handing over the call to the carrier or service 
provider identified by the CIC and the local policies require it to 
remove the "cic" parameter. How the call is actually routed based 
on the CIC value in the "cic" parameter is outside the scope of 
this document. 


When looking for the "rn" parameter and that parameter exists in the 
"tel" URI: 


- If the routing number in the "rn" parameter points to this network 
node (e.g., the call has reached the intended network node), this 
network node MUST look for the freephone number or geographical 
telephone number for making the routing decision. It MUST remove 
the "rn" parameter when setting up the call to the next-hop network 
node regardless if that next-hop network node is in the same or 
different network. 
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- If the routing number in the "rn" parameter points to a network 
this network node is in (e€.g., in some countries the routing number 
gets the call to the serving carrier network where another NP 
database access is required to locate the serving switch), this 
network node MUST look for the freephone number or geographical 
telephone number for making the routing decision. The network node 
MAY access the NP database for routing information if it is set to 
do so. It MUST remove the "rn" parameter if the next-hop network 
node belongs to another carrier or service provider. 


- Otherwise, the network node MUST make the routing decision based on 
the routing number in the "rn" parameter. How the call is actually 
routed based on the routing number in the "rn" parameter is outside 
the scope of this document. 


When the "cic" or "rn" parameter is not used for routing, the network 
node uses the freephone number or geographical telephone number for 
making routing decisions. It may access the NP database if it is set 
to do so, or it may route the call to a designated network node that 
will access the NP database, or it may route the call based on the 
local routing table. How the call is handled at this stage is 
outside the scope of this document. See Section 5.2 for rules in 
adding the parameter or parameters defined in this document to the 
"tel" URI if the network node is set to access the NP database. 


-2. Adding NP Parameter or Parameters to the "tel" URI 


There are two cases in terms of NP database access. One is fora 
geographical telephone number and the other is for a freephone 
number. They are discussed in Sections 5.2.1 and 5.2.2 for a "tel" 
URI that is used for routing. 


Section 5.2.3 discusses a special case where the "rn" parameter is 
added to a "tel" URI that is associated with the first network node 
that handles the call request from the caller. Section 5.2.4 
discusses the addition of the parameter or parameters defined in this 
document to the "tel" URI due to protocol conversion. 


-2.1. Retrieving NP-related Information for a Geographical Telephone 


Number 


When a network node accesses an NP database for a geographical 
telephone number: 


- If the network node retrieves a routing number, it MUST add the 
"rn" parameter to the "tel" URI to carry the routing number 
information in the "global-rn" or "local-rn" format. It MUST also 
add the "npdi" parameter. 
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If the network node does not retrieve a routing number (e.g., fora 
non-ported geographical telephone number), it MUST add the "npdi" 
parameter to the "tel" URI. 


The network node MUST follow the rules described in Section 5.1 for 
using the information in the "tel" URI to make the routing decision. 


Za 


Retrieving NP-related Information for a Freephone Number 


When a network node performs the first or second freephone database 
access for a freephone number: 


If the network node retrieves a CIC that identifies a carrier or 
service provider associated with that network node, or indicates 
that a geographic number is supplied (e.g., "+1-0110" means "local, 
translated geographical telephone number provided"), it would have 
retrieved a geographical telephone number. The network node MUST 
NOT add the "cic" parameter and MUST replace the freephone number 
in the "tel" URI with the retrieved geographical telephone number 
in either the "global-number" or "local-number" format. 


Some freephone databases may not return the geographical telephone 
number but internal routing information in a proprietary format 
(e.g., switch ID and trunk group ID). That case is outside the 
scope of this document. 


If the network node retrieves a CIC that belongs to another 
freephone service provider, the network node MUST add the "cic" 
parameter to the "tel" URI that contains the CIC in the "global- 
cic" or "local-cic" format. 


The originating carrier may have business agreements with a 
freephone service provider to return the geographical telephone 
number in addition to the CIC. When a geographical telephone 
number is returned, the network node MUST replace the freephone 
number in the "tel" URI with the returned geographical telephone 
number in either the "global-number" or "local-number" format. 


If the network node retrieves a geographical telephone number 
(which is the typical case for the second freephone database 
access), the network node MUST replace the freephone number in the 
"tel" URI with the retrieved geographical telephone number in 
either the "global-number" or "local-number" format. 


When a geographical telephone number is returned in the response, 
it is possible that the NP-related information for that 
geographical telephone number could also be returned. In that 
case, the network node MUST add the "npdi" parameter and MUST add 
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the "rn" parameter to contain the routing number in either the 
"global-rn" or "local-rn" format only when the routing number is 
available. 


The network node MUST follow the rules described in Section 5.1 for 
using the information in the "tel" URI to make the routing decision. 


-2.3. Adding Location Information about the Caller 


In SS7 ISUP, the JIP identifies the switch that originates the call, 
and the information in it may be used by the serving carrier to 
determine the call charge to the caller or by the involved carriers 
to determine the settlement amount between them. 


A network node that is the first to handle the call request from the 
caller MAY include the "rn" parameter to the "tel" URI associated 
with the caller, if one exists. For example, if the network node is 
a Global Switched Telephone Network (GSTN) gateway that receives an 
ISUP message that contains the JIP, the correct location information 
in the JIP can be placed in the "rn" parameter of the "tel" URI that 
is associated with the caller. 


Please note that the information in the "rn" parameter may not be 
authenticated; therefore, the use of the information by the recipient 
of the "tel" URI for anything related to charging is done at its own 
risk. 


-2.4. Adding NP Parameter or Parameters Due to Protocol Conversion 


A GSTN gateway needs to convert between SS7 ISUP and the VoIP 
protocol such as SIP or H.323. This type of network node MUST map 
between the corresponding ISUP parameters and the parameters defined 
in this document associated with the "tel" URI for routing and MAY 
map between the corresponding ISUP parameters and the parameters 
defined in this document that are in the "tel" URI associated with 
the caller. 


Since ISUP support for NP depends on the individual country, the 
following discussion applies to a situation when a network node is to 
map between the NP information in the American National Standards 
Institute (ANSI) ISUP and the NP-related parameters in the "tel" URI. 


For a ported geographical telephone number, the network node MUST 
convert the routing number in the ISUP Called Party Number parameter 
to a routing number in either the "global-rn" or "local-rn" format 
and carry it in the "rn" parameter for a "tel" URI that is used for 
routing. The network node MUST convert the phone number that is 
marked as the "ported number" in the ISUP Generic Address Parameter 
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(GAP) to a phone number in either the "global-number" or "local- 
number" format [RFC3966] and put it in the global-number-digits or 
local-number-digits (see [RFC3966]) part of the "tel" URI that is 
used for routing. 


For a non-ported geographical telephone number, the network node MUST 
convert the phone number in the ISUP Called Party Number parameter to 
a phone number in either the "global-number" or "local-number" format 
and put it in the global-number-digits or local-number-digits (see 
[RFC3966]) part of the "tel" URI that is used for routing. The "rn" 
parameter MUST NOT appear in the "tel" URI unless the local policies 
require the network node to include it. It is outside the scope of 
this document how to include the "rn" parameter if the local policies 
require the network node to do so. 


The network node MUST include the "npdi" parameter in the "tel" URI 
that is used for routing when the Ported Number Translation Indicator 
(PNTI) bit in the Forward Call Indicator (FCI) parameter is set to 
"ny 


The network node MUST include the "cic" parameter in either the 
"global-cic" or "local-cic" format in the "tel" URI that is used for 
routing when the ISUP Carrier Identification Parameter (CIP) is 
present. 


The network node MAY include the "rn" parameter in the "tel" URI 
associated with the caller information when the ISUP JIP is present. 
This may be subject to the network node’s local policy and/or the 
signaling protocol that carries the "tel" URI. 


Mapping NP-related parameters in a "tel" URI to the NP-related 
information in the ISUP message depends on the national ISUP 
implementation and is outside the scope of this document. 


6. Examples 


A. A "tel" URI, tel:+1-800-123-4567, contains a freephone number 
"+1-800-123-4567". Assume that this freephone number is served by 
a freephone service provider with a CIC "+1-6789". After 
retrieving the NP-related information, the "tel" URI would be set 
to 


tel:+1-800-123-4567; cic=+1-6789 
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B. A "tel" URI, tel:+1-800-123-4567; cic=+1-6789, is handled by a 
network node in the serving freephone service provider’s network. 
Assume that the freephone number is mapped to a geographical 
telephone number "+1-202-533-1234". After retrieving the NP- 
related information, the "tel" URI would be set to 


tel:+1-202-533-1234 


C. A "tel" URI, tel:+1-202-533-1234, contains a geographical 


telephone number "+1-202-533-1234". Assume that this geographical 
telephone number is ported and is associated with a routing number 
"1-202-544-0000". After retrieving the NP-related information, 


the "tel" URI would be set to 
tel:+1-202-533-1234; npdi; rn=+1-202-544-0000 


D. A "tel" URI, tel:+1-202-533-6789, contains a geographical 
telephone number "+1-202-533-6789". Assume that this geographical 
telephone number is not ported. After accessing the NP database, 
the "tel" URI would be set to 


tel:+1-202-533-6789;npdi 


E. A "tel" URI, tel:+1-202-533-1234; npdi; rn=+1-202-000-0000, contains 
an invalid routing number (e.g., no routing information on "+1- 
202-000-0000"); the network node may drop the "rn" parameter and 
access the NP database again. 


F. A "tel" URI, tel:+1-800-123-456, contains a freephone number 
"+1-800-123-456" that is one digit short. When accessing the 
freephone database, there will not be any "cic" information for 
this freephone number. The call would be released. 


G. A "tel" URI, tel:+1-800-123-4567; cic=+1-56789, is handled by a 


network node in an originating or a transit network. The "cic" 
information is invalid. The network node may drop the "cic" 
parameter and access the freephone database again. If the same 


wrong CIC information is received, the network node would release 
the call because it does not know how to route the call with an 


invalid CIC. If valid information is received, the network node 
will use the received CIC in the "cic" and route the call based on 
the “eic™. 
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Security Considerations 


In addition to those security implications discussed in the revised 
"tel" URI [RFC3966], there are new security implications associated 
with the parameters defined in this document. 


If the value of the "rn" or "cic" in the "tel" URI is changed 
illegally when the signaling message carrying the "tel" URI is en 
route to the destination entity, the signaling message or call may be 
routed to the wrong network or network node causing the call setup to 
be rejected. 


If the "npdi" is illegally inserted into the "tel" URI when the 
signaling message carrying the "tel" URI is en route to the 
destination entity, the call may be routed to the wrong network or 
network node causing the call setup to be rejected. It is less a 
problem if the "npdi" is illegally removed. An additional NPDB query 
may be performed to retrieve the routing number information and have 
the "npdi" included again. 


If the "rn" in the "tel" URI that is associated with the caller is 
illegally changed or inserted, the call charge based on that "rn" 
would be incorrect. 


Because of these considerations, these "tel" URI extensions are only 
applicable within a set of network nodes among which there is mutual 
trust. If a node receives a call signaling request from an upstream 
node that it does not trust, it SHOULD remove these parameters. This 
will generally cause it to redo any DB queries. 


To verify that an upstream neighbor is trusted, and to prevent man- 
in-the-middle attacks whereby an attacker inserts or modifies these 
parameters, call signaling protocols carrying these parameters SHOULD 
provide hop-by-hop message integrity. In the case of SIP, this is 
accomplished with the Session Initiation Protocol Secure (SIPS) URI 
mechanism. 
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